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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained 
in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
substantially correct. The changes are as follows: 
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WITHDRAWN REJECTIONS 

The following grounds of rejection are not presented for review on appeal because 
they have been withdrawn by the examiner. The rejection of claims 79, 80, and 82 under §112, 
second paragraph is withdrawn. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

US 6721334 Ketcham 4-2004 

US 5781726 Pereira 7-1998 

US 5964837 Chao et al 10-1999 

Simpson ("RFC 1661: Point-'to-Point Protocol", July 1994) 

Rosenberg et al. ("An RTP Payload Format for User Multiplexing," May 1998) 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claim Rejections - 35 USC § 103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art 
are such that the subject matter as a whole would have been obvious at the time the invention was made to a 
person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be 
negatived by the manner in which the invention was made. 
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1. Claims 1-4, 8-10, 14-16, 21-23, 25, 29, 30, 35'40> 42, 46-50, 59, 60, 69, 72, 75, and 78-85 are 
rejected under 35 U.S.C. 103(a) as being unpatentable over Ketcham (U.S. Patent Number 
6,721,334) in view of Pereira (U.S. Patent Number 5,781,726). 

2. Ketcham disclosed a method for improving the efficiency of a packet-based network 
by using aggregate packets. In an analogous art, Pereira disclosed a method for managing 
polling traffic in a set of connection oriented sessions between end stations in a network. 
Both systems deal with data transfer from at least one end node, through a first router or 
edge device, through a second router or edge device, and to at least one second end node. 

3. Concerning the independent claims, although Ketcham describes a system in which 
different types of data packets can be aggregated together, he did not explicitly state the use 
of a keep-alive message or poll request. However, Pereira's system is focused on the polling 
of point-to-point devices and explicitly states the use of a poll request from a first to a second 
end system and a poll response from the second to the first end system. It would have been 
obvious to one of ordinary skill in the art at the time of the applicant's invention to modify 
the system of Ketcham by adding the ability to use keep-alive messages as the data packets as 
provided by Pereira. Here the combination would satisfy the need for an improved 
connection oriented protocol for systems that maintain a number of end users that share a 
common link. See Pereira, column 4, lines 12-17. This rationale also applies to those 
dependent claims utilizing the same combination. 
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4. Thereby, the combination of Ketcham and Pereira discloses: 

• <Claim i> 

A method of processing a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
implemented on a communication network, said method comprising: receiving in an 
aggregation device (Ketcham, figure 4, item 308) said plurality of keep-alive messages 
(Pereira, column 4, lines 31-34); generating in said aggregation device an aggregated 
request packet which includes data indicating that the status of said PPP sessions is 
requested (Ketcham, column 7, line 62 through column 8, line 4, wherein the 
aggregated packet contains the poll requests as disclosed by Pereira); and sending said 
aggregated request packet to a peer aggregation device (Ketcham, figure 4, item 314). 

• <Claim 2> 

The method of claim 1, further comprising: receiving said aggregated request 
packet in said peer aggregation device (Ketcham, column 8, lines 15-22); indicating the 
status of said plurality of sessions in an aggregated reply packet (Pereira, column 6, 
lines 1-6, wherein Pereira's response polls may be aggregated at Ketcham's router 314); 
and sending said aggregated reply packet to said aggregation device (Ketcham, figure 
4, inherently data packets can also flow from router 314 to router 308). 

• <Claim 3> 

The method of claim 1, further comprising receiving in said aggregation device 
an aggregated reply packet from said peer aggregation device, wherein said aggregated 
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reply packet indicates the status of at least some of said plurality of PPP sessions 
(Pereira, column 6, lines 1-6). 

• <Claim 4> 

The method of claim 3, further comprising sending from said aggregation 
device a proxy keep-alive reply message to one of said plurality of end systems 
originating a corresponding one of said keep alive-messages without waiting for said 
aggregated reply packet (Pereira, column 5, lines 45-47). 

• <Claim 8> 

The method of claim 1, wherein said communication network is implemented 
using one of frame relay, ATM and IP networks (Ketcham, column 1, lines 33-48). 

• <Claim 9> 

The method of claim 1, wherein said aggregation device is one of a network 
access server and home gateway (Ketcham, column 4, lines 37-43). 

• <Claim io> 

A method of processing an aggregated request packet in an aggregation device, 
wherein said aggregated request packet is received from a peer aggregation device and 
indicates that the status of a plurality of point-to-point sessions is requested, said 
method comprising: examining said aggregated request packet to determine that the 
status of said plurality of point-to-point sessions is requested (Ketcham, column 8, 
lines 15-22, wherein the aggregated packet contains the poll requests as disclosed by 
Pereira); determining the status of each of said plurality of point-to-point sessions 
(Pereira, column 6, lines 1-6 and 50-55); generating an aggregated reply packet 
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indicating the status of said plurality of point- to-point sessions (Pereira, column 6, 
lines 1-6, wherein Pereira's response polls may be aggregated at Ketcham's router 314); 
and sending said aggregated reply packet to said peer aggregation device (Ketcham, 
figure 4, inherently data packets can also flow from router 314 to router 308). 

• <Claim I4> 

The method of claim 10, wherein said aggregation device comprises one of a 
network access server (NAS) and a home gateway implemented in a communication 
network (Ketcham, column 4, lines 37-43). 

• <Claim I5> 

An aggregation device for processing a plurality of keep-alive messages 
generated by a corresponding plurality of end systems, each of said plurality of keep- 
alive messages being designed to request the status of a corresponding point to point 
(PPP) session implemented on a communication network, said aggregation device 
comprising: an input interface receiving said plurality of keep-alive messages 
(Ketcham, figure 4, item 308 and Pereira, column 4, lines 31-34); a message aggregator 
coupled to said input interface, said message aggregator examining said plurality of 
message and generating data according to a format indicating that the status of said 
PPP sessions is requested (Ketcham, column 7, line 62 through column 8, line 4, 
wherein the aggregated packet contains the poll requests as disclosed by Pereira); and 
an output interface sending an aggregated request packet on said communication 
network to a peer aggregation device, said aggregated request packet containing said 
data generated by said message aggregator (Ketcham, figure 4, item 314). 
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• <Claim i6> 

The aggregation device of claim 15, further comprising an encapsulator 
encapsulating said data in a packet suitable for transmission on said communication 
network (Pereira, column 2, lines 19-25, wherein encapsulation is inherent to PPP). 

• <Claim 2i> 

An aggregation device for processing a plurality of keep-alive messages 
generated by a corresponding plurality of end systems, each of said plurality of keep- 
alive messages being designed to request the status of a corresponding point to point 
(PPP) session implemented on a communication network, said aggregation device 
comprising: first means for receiving said plurality of keep-alive messages (Ketcham, 
figure 4, item 308 and Pereira, column 4, lines 31-34); means for generating an 
aggregated request packet which includes data indicating that the status of said PPP 
sessions is requested (Ketcham, column 7, line 62 through column 8, line 4, wherein 
the aggregated packet contains the poll requests as disclosed by Pereira); and means 
for sending said aggregated request packet to a peer aggregation device (Ketcham, 
figure 4, item 314). 

• <Claim 22> 

The aggregation device of claim 21, further comprising second means for 
receiving an aggregated reply packet from said peer aggregation device (Ketcham, 
figure 4, inherently data packets can also flow from router 314 to router 308), wherein 
said aggregated reply packet indicates the status of at least some of said plurality of 
PPP sessions (Pereira, column 6, lines 1-6). 
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• <Claim 23> 

The aggregation device of claim 22, further comprising means for sending a 
proxy keep-alive reply message to one of said plurality of end systems originating a 
corresponding one of said keep alive-messages without waiting for said aggregated 
reply packet (Pereira, column 5, lines 45-47). 

• <Claim 25> 

An aggregation device for processing an aggregated request packet, wherein 
said aggregated request packet is received from a peer aggregation device and indicates 
that the status of a plurality of point-to-point sessions are requested, said aggregation 
device comprising: means for examining said aggregated request packet to determine 
that the status of said plurality of point-to-point sessions is requested (Ketcham, 
column 8, lines 15-22, wherein the aggregated packet contains the poll requests as 
disclosed by Pereira); means for determining the status of each of said plurality of 
point-to-point sessions (Pereira, column 6, lines 1-6 and 50-55); means for generating 
an aggregated reply packet indicating the status of said plurality of point-to-point 
sessions (Pereira, column 6, lines 1-6, wherein Pereira's response polls may be 
aggregated at Ketcham's router 314); and means for sending said aggregated reply 
packet to said peer aggregation device (Ketcham, figure 4, inherently data packets can 
also flow from router 314 to router 308). 



Application/Control Number: 09/785,884 Page 10 

Art Unit: 2152 

• <Claim 29> 

The aggregation device of claim 25, wherein said aggregation device comprises 
one of a network access server (NAS) and a home gateway implemented in a 
communication network (Ketcham, column 4, lines 37-43). 

• <Claim 30> 

An aggregation device for processing an aggregated request packet, wherein 
said aggregated request packet is received from a peer aggregation device and indicates 
that the status of a plurality of point-to-point sessions are requested, said aggregation 
device comprising: an input interface receiving said aggregated request packet 
(Ketcham, figure 4, item 314, wherein the aggregated packet contains the poll requests 
as disclosed by Pereira); a de-encapsulator examining said aggregated request packet 
to determine that the status of said plurality of point-to-point sessions is requested 
(Ketcham, column 8, lines 15-22); a reply generator determining the status of each of 
said plurality of point-to-point sessions, and generating an aggregated reply packet 
indicating the status of each of said plurality of point-to-point sessions (Pereira, 
column 6, lines 1-6, wherein Pereira's response polls may be aggregated at Ketcham's 
router 314); and an output interface sending said aggregated reply packet to said peer 
aggregation device (Ketcham, figure 4, inherently data packets can also flow from 
router 314 to router 308). 

• <Claim 35> 

The aggregation device of claim 30, further comprising a keep-alive processor 
coupled to said de-encapsulator, wherein said keep-alive processor examines said 
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aggregated request packet to determine that status of point-to-point sessions is 
requested and causes said reply generator to generate said aggregated reply packet 
(Ketcham, column 8, lines 15-22 and Pereira, column 6, lines 1-6). 

• <Claim $6> 

The aggregation device of claim 30, wherein said aggregation device comprises 
one of a network access server (NAS) and a home gateway implemented in a 
communication network (Ketcham, column 4, lines 37-43). 

• <Claim 37> 

A computer-readable medium carrying one or more sequences of instructions 
for causing a aggregation device to process a plurality of keep-alive messages 
generated by a corresponding plurality of end systems, each of said plurality of keep- 
alive messages being designed to request the status of a corresponding point to point 
(PPP) session implemented on a communication network, wherein execution of said 
one or more sequences of instructions by one or more processors contained in said 
aggregation device causes said one or more processors to perform the actions of: 
receiving in an aggregation device (Ketcham, figure 4, item 308) said plurality of keep- 
alive messages (Pereira, column 4, lines 31-34); generating in said aggregation device 
an aggregated request packet which includes data indicating that the status of said 
PPP sessions is requested (Ketcham, column 7, line 62 through column 8, line 4, 
wherein the aggregated packet contains the poll requests as disclosed by Pereira); and 
sending said aggregated request packet to a peer aggregation device (Ketcham, figure 
4, item 314). 
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• <Claim 38> 

The computer-readable medium of claim 37, further comprising: receiving said 
aggregated request packet in said peer aggregation device (Ketcham, column 8, lines 
15-22); indicating the status of said plurality of sessions in an aggregated reply packet 
(Pereira, column 6, lines 1-6, wherein Pereira's response polls may be aggregated at 
Ketcham's router 314); and sending said aggregated reply packet to said aggregation 
device (Ketcham, figure 4, inherently data packets can also flow from router 314 to 
router 308). 

• <Claim 39> 

The computer-readable medium of claim 37, further comprising receiving in 
said aggregation device an aggregated reply packet from said peer aggregation device, 
wherein said aggregated reply packet indicates the status of at least some of said 
plurality of PPP sessions (Pereira, column 6, lines 1-6). 

• <Claim 40> 

The computer-readable medium of claim 39, further comprising sending a proxy keep- 
alive reply message to one of said plurality of end systems originating a corresponding 
one of said keep alive-messages without waiting for said aggregated reply packet 
(Pereira, column 5, lines 45-47). 

• <Claim 42> 

A computer-readable medium carrying one or more sequences of instructions 
for causing an aggregation device to process an aggregated request packet, wherein 
said aggregated request packet is received from a peer aggregation device and indicates 
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that the status of a plurality of point-to-point sessions are requested, wherein 
execution of said one or more sequences of instructions by one or more processors 
contained in said aggregation device causes said one or more processors to perform the 
actions of: examining said aggregated request packet to determine that the status of 
said plurality of point-to-point sessions is requested (Ketcham, column 8, lines 15-22, 
wherein the aggregated packet contains the poll requests as disclosed by Pereira); 
determining the status of each of said plurality of point-to-point sessions (Pereira, 
column 6, lines 1-6 and 50-55); generating an aggregated reply packet indicating the 
status of said plurality of point- to-point sessions (Pereira, column 6, lines 1-6, 
wherein Pereira's response polls may be aggregated at Ketcham's router 314); and 
sending said aggregated reply packet to said peer aggregation device (Ketcham, figure 
4, inherently data packets can also flow from router 314 to router 308). 

• <Claim 46> 

The computer-readable medium of claim 42, wherein said aggregation device 
comprises one of a network access server (NAS) and a home gateway implemented in 
a communication network (Ketcham, column 4, lines 37-43). 

• <Claim 47> 

A communication network comprising: a first aggregation device (Ketcham, 
figure 4, item 308) receiving a plurality of keep-alive messages (Pereira, column 4, 
lines 31-34) generated by a corresponding plurality of end systems, each of said 
plurality of keep-alive messages being designed to request the status of a 
corresponding point to point (PPP) session implemented on said communication 
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network, said first aggregation device generating an aggregated request packet which 
includes data indicating that the status of said PPP sessions is requested (Ketcham, 
column 7, line 62 through column 8, line 4, wherein the aggregated packet contains the 
poll requests as disclosed by Pereira), and sending said aggregated request packet 
(Ketcham, column 7, line 62 through column 8, line 4); and a peer aggregation device 
(Ketcham, figure 4, item 314) receiving said aggregated request packet and indicating 
the status of said plurality of sessions in an aggregated reply packet (Pereira, column 
6, lines 1-6, wherein Pereira's response polls may be aggregated at Ketcham's router 
314), said peer aggregation packet sending said aggregated reply packet to said first 
aggregation device (Ketcham, figure 4, inherently data packets can also flow from 
router 314 to router 308), wherein each of said first aggregation device and said peer 
aggregation device is implemented as a single device (Ketcham, figure 4, items 308 
and 314). 

• <Claim 48> 

The communication network of claim 47, wherein said first aggregation device 
is located at an edge of said communication networks (Ketcham, figure 4, item 308). 

• <Claim 49> 

The communication network of claim 48, further comprising an access 
network coupling said first aggregation device to said corresponding plurality of end 
systems, wherein said plurality of keep-alive messages are received on said access 
network (Ketcham, figure 4, item 106). 
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• <Claim 50 

The communication network of claim 49, wherein said first aggregation device 
and said peer aggregation device respectively comprise a network access server (NAS) 
and a home gateway (Ketcham, column 4, lines 37-43). 

• <Claim 59> 

The method of claim 1, wherein said aggregation device is physically separate 
from said plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim 6o> 

The method of claim 10, wherein said aggregation device is physically separate 
from said plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim 6g> 

The method of claim 1, wherein each of said PPP sessions terminates at a 
home gateway, and wherein said aggregation device comprises a switching device and 
is in the path of each of said PPP sessions from a corresponding one of said plurality 
of end systems to said home gateway (Ketcham, figure 4, item 308). 

• <Claim 72> 

The aggregation device of claim 30, wherein each of said PPP sessions 
terminates at a home gateway, and wherein said aggregation device comprises a 
switching device and is in the path of each of said PPP sessions from a corresponding 
one of said plurality of end systems to said home gateway (Ketcham, figure 4, item 
314). 
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• <Claim 75> 

The computer readable medium of claim 37, wherein each of said PPP sessions 
terminates at a home gateway, and wherein said aggregation device comprises a 
switching device and is in the path of each of said PPP sessions from a corresponding 
one of said plurality of end systems to said home gateway (Ketcham, figure 4, item 

308). 

• <Claim 78> 

The aggregation device of claim 21, wherein each of said PPP sessions 
terminates at a home gateway, and wherein said aggregation device comprises a 
switching device and is in the path of each of said PPP sessions from a corresponding 
one of said plurality of end systems to said home gateway (Ketcham, figure 4, item 

308). 

• <Claim 79> 

The method of claim 1, wherein said receiving, said generating and said 
sending are performed in an aggregation device implemented as a single device 
(Ketcham, figure 4, item 308). 

• <Claim 8o> 

The method of claim 10, wherein said examining, said determining, said 
generating and said sending are performed in said aggregation device implemented as 
a single device (Ketcham, figure 4, item 308). 
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• <Claim 8i> 

The aggregation device of claim 21, wherein said means for receiving, said 
means for generating and said means for sending are contained in said aggregation 
device implemented as a single device (Ketcham, figure 4, item 308). 

• <Claim 82> 

The aggregation device of claim 25, wherein said means for examining, said 
means for determining, said means for generating and said means for sending are 
implemented in said aggregation device implemented as a single device (Ketcham, 
figure 4, item 308) 

• <Claim 83> 

The aggregation device of claim 30, wherein said input interface, said de- 
encapsulator, said reply generator and said output interface are contained in said 
aggregation device implemented as a single device (Ketcham, figure 4, item 308). 

• <Claim 84> 

The computer readable medium of claim 37, wherein said receiving, said 
generating and said sending are performed by said aggregation device implemented a 
a single device (Ketcham, figure 4, item 308). 

• <Claim 85> 

The computer readable medium of claim 42, wherein said examining, said 
determining, said generating and said sending are performed by said aggregation 
device implemented as a single device (Ketcham, figure 4, item 308). 
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Since the combination of Ketcham and Pereira discloses all of the above limitations, 
claims 1-4, 8-10, 14-16, 21-23, 25, 29, 30, 35*40, 42, 46-50, 59, 60, 69, 72, 75, and 78-85 are rejected. 

5. Claims 5-7, 11, 13, 17-19, 24, 26, 28, 31, 32, 34, 41, 43, and 45 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Ketcham in view of Pereira, as applied above, further in 
view of Chao et al. (U.S. Patent Number 5,964,837), hereinafter referred to as Chao. 

6. The combination of Ketcham and Pereira disclosed a method for managing polling 
traffic in a set of connection oriented sessions between end stations in a network that uses 
aggregation of packets. In an analogous art, Chao disclosed a method of monitoring the 
topology of a network using polling and event-monitoring. Just as the combination of 
Ketcham and Pereira, Chao's system is utilized in point-to-point networks. 

7. Concerning claim 5, although the combination of Ketcham and Pereira did not 
explicitly state the use of a table to track the status of sessions in the network, Chao's main 
focus is a table or topology map, containing information about the operability of nodes in his 
system. It would have been obvious to one of ordinary skill in the art at the time of the 
applicant's invention to modify the combination of Ketcham and Pereira by adding a status 
table as provided by Chao. Here the combination satisfies the need for an improved method 
of monitoring a point-to-point network. See Chao, column 2, lines 15-24. This rationale also 
applies to other similar dependent claims utilizing the same combination. 
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8. Thereby, the combination of Ketcham, Pereira, and Chao discloses: 

• <Claim 5> 

The method of claim 4, further comprising: maintaining a remote status table 
in said aggregation device, wherein said remote status table indicates the status of 
sessions supported by said aggregation device (Chao, column 5, lines 46-50); updating 
said remote status table with the information in said aggregated reply packet (Chao, 
column 6, lines 1-13); and generating said proxy keep-alive reply according to said 
remote status table (Chao, column 6, lines 55-65). 

• <Claim 6> 

The method of claim 5, wherein said proxy keep-alive message indicates that 
the corresponding session is alive/OK when a first keep-alive message is received for 
the corresponding session (Pereira, column 10, lines 29-38). 

• <Claim 7> 

The method of claim 6, further comprising initializing the status of each of 
said session to alive/OK such that said proxy keep-alive message in response to said 
first keep-alive message indicates alive/OK status (Pereira, column 10, lines 18-28). 

• <Claim n> 

The method of claim 10, wherein said determining comprises accessing a local 
status table which contains the status information of at least some of said plurality of 
point- to-point sessions (Chao, column 8, lines 52-58). 
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• <Claim I3> 

The method of claim 10, wherein said generating comprises setting a bit to one 
logical value to indicate that a corresponding one of said plurality of sessions is 
OK/alive, and to another logical value to indicate that said corresponding one of said 
plurality of session not OK/alive (Chao, column 5, lines 50-53). 

• <Claim i7> 

The aggregation device of claim 16, further comprising: a remote status table 
indicating the status of sessions supported by said aggregation device (Chao, column 
5, lines 46-50); and a de-aggregator receiving an aggregated reply packet from said peer 
aggregation device, wherein said aggregated reply packet indicates the status of at 
least some of said plurality of PPP sessions, said de-aggregator updating said remote 
status table with the information in said aggregated reply packet (Chao, column 6, 
lines 1-13). 

• <Claim i8> 

The aggregation device of claim 17, further comprising a proxy reply unit 
sending a proxy keep-alive reply message to one of said plurality of end systems 
originating a corresponding one of said keep alive-messages without waiting for said 
aggregated reply packet (Pereira, column 5, lines 45-47). 

• <Claim I9> 

The invention of claim 18, wherein said aggregation device comprises a 
network access server (Ketcham, column 4, lines 37-43). 
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• <Claim 24> 

The aggregation device of claim 23, further comprising: means for maintaining 
a remote status table in said aggregation device, wherein said remote status table 
indicates the status of sessions supported by said aggregation device (Chao, column 5, 
lines 46-50); means for updating said remote status table with the information in said 
aggregated reply packet (Chao, column 6, lines 1-13); and means for generating said 
proxy keep-alive reply according to said remote status table (Chao, column 6, lines 55- 
6s). 

• <Claim 26> 

The aggregation device of claim 25, wherein said means for determining 
comprises means for accessing a local status table which contains the status 
information of at least some of said plurality of point-to-point sessions (Chao, 
column 8, lines 52-58). 

• <Claim 28> 

The aggregation device of claim 25, wherein said means for generating sets a 
bit in said aggregated reply packet to one logical value to indicate that a corresponding 
one of said plurality of sessions is OK/alive, and to another logical value to indicate 
that said corresponding one of said plurality of session not OK/alive (Chao, column 5, 
lines 50-53). 

• <Claim 3i> 

The aggregation device of claim 30, further comprising a local status table 
storing the status information of at least some of said plurality of point-to-point 
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sessions, wherein said reply generator determines the status of said at least some of 
said plurality of point-to- point sessions by accessing said local status table (Chao, 
column 8, lines 52-58). 

• <Claim 32> 

The aggregation device of claim 31, further comprising a session manager 
updating the status of said plurality of point-to-point sessions in said local status table 
(Chao, column 7, lines 64-66). 

• <Claim 34> 

The aggregation device of claim 30, wherein said reply generator sets a bit in 
said aggregated reply packet to one logical value to indicate that a corresponding one 
of said plurality of sessions is OK/alive, and to another logical value to indicate that 
said corresponding one of said plurality of session not OK/alive (Chao, column 5, 
lines 50-53). 

• <Claim 4i> 

The computer-readable medium of claim 40, further comprising: maintaining a 
remote status table in said aggregation device, wherein said remote status table 
indicates the status of sessions supported by said aggregation device (Chao, column 5, 
lines 46-50); updating said remote status table with the information in said aggregated 
reply packet (Chao, column 6, lines 1-13); and generating said proxy keep-alive reply 
according to said remote status table (Chao, column 6, lines 55-65). 
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• <Claim 43> 

The computer-readable medium of claim 42, wherein said determining 
comprises accessing a local status table which contains the status information of at 
least some of said plurality of point-to-point sessions (Chao, column 8, lines 52-58). 

• <Claim 45> 

The computer-readable medium of claim 42, wherein said generating 
comprises setting a bit to one logical value to indicate that a corresponding one of said 
plurality of sessions is OK/aiive, and to another logical value to indicate that said 
corresponding one of said plurality of session not OK/alive (Chao, column 5, lines 50- 

53). 

Since the combination of Ketcham, Pereira, and Chao discloses all of the above 
limitations, claims 5-7, 11, 13, 17-19, 24, 26, 28, 31, 32, 34, 41, 43, and 45 are rejected. 

9. Claims 12, 20, 27, 33, and 44 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Ketcham in view of Pereira further in view of Chao, as applied above, further in view of 
Simpson ("RFC 1661: Point-to-Point Protocol," July 1994). 

10. The combination of Ketcham, Pereira, and Chao disclosed a method for managing 
polling traffic in a set of connection oriented sessions between end stations in a point-to- 
point network by aggregating packets and maintaining a status table. In an analogous art, 
Simpson disclosed an overview of the point-to-point protocol. 
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n. Concerning claim 12, although the combination of Ketcham, Pereira, and Chao did not 
explicitly teach the use of a magic number associated with each session, Simpson taught a 
magic number for use with the point-to-point protocol. It would have been obvious to one of 
ordinary skill in the art at the time of the applicant's invention to modify the combination of 
Ketcham, Pereira, and Chao by adding a magic number as provided by Simpson. Again the 
combination satisfies the need for an improved method of monitoring a point-to-point 
network. See Chao, column 2, lines 15-24. This rationale also applies to other similar 
dependent claims utilizing the same combination. 

12. Thereby, the combination of Ketcham, Pereira, Chao, and Simpson discloses: 

• <Claim i2> 

The method of claim 10, wherein said generating comprises including a client 
magic number associated with each of said plurality of point-to-point sessions 
(Simpson, pages 45-47). 

• <Claim 20> 

The aggregation device of claim 18, wherein said aggregated request packet 
contains a magic number related to each of the corresponding sessions (Simpson, 
pages 45-47)- 

• <Claim 27> 

The aggregation device of claim 25, wherein said means for generating includes 
a client magic number associated with each of said plurality of point-to-point sessions 
(Simpson, pages 45-47). 
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• <Claim 33> 

The aggregation device of claim 30, wherein said reply generator includes in 
said aggregated reply packet a client magic number associated with each of said 
plurality of point-to-point sessions (Simpson, pages 45-47). 

• <Claim 44> 

The computer-readable medium of claim 42, wherein said generating 
comprises including a client magic number associated with each of said plurality of 
point-to-point sessions (Simpson, pages 45-47). 

Since the combination of Ketcham, Pereira, Chao, and Simpson discloses all of the 
above limitations, claims 12, 20, 27, 33, and 44 are rejected. 

13. Claims 67, 68, 70, 71, 73, 74, 76, and 77 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Ketcham in view of Pereira, as applied above, further in view of Rosenberg 
et al. ("An RTP Payload Format for User Multiplexing," May 1998), hereinafter referred to 
as Rosenberg. 

14. The combination of Ketcham and Pereira disclosed a method for managing polling 
traffic in a set of connection oriented sessions between end stations in a network that uses 
aggregation of packets. In an analogous art, Rosenberg disclosed a method of aggregating 
RTP data for multiple users in a point-to-point system. Just as the combination of Ketcham 
and Pereira, Rosenberg's system is utilized in point-to-point networks. 
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15. Concerning claims 67, 68, 70, 71, 73, 74, 76, and 77, although the combination of 
Ketcham and Pereira did not explicitly state that the aggregated message contains less data 
than the plurality of the non-aggregated messages together, this is a well known result in 
message aggregation. This is evidenced by Rosenberg whose system creates an aggregated 
message that is smaller than the sum of the original messages in order to improve packet 
efficiency. It would have been obvious to one of ordinary skill in the art at the time of the 
applicant's invention to modify the combination of Ketcham and Pereira by adding the 
ability for the message aggregator to generate less data in the aggregated message than the 
data forming the plurality of messages together as provided by Rosenberg. Here the 
combination satisfies the need for an improved connection oriented protocol for systems that 
maintain a number of end users that share a common link. See Pereira, column 4, lines 12-17. 
This rationale also applies to similar dependent claims utilizing the same combination. 

16. Thereby, the combination of Ketcham, Pereira, and Rosenberg discloses: 

• <Claim 67> 

The method of claim 1, wherein said generating includes less data in said 
aggregated request packet than the data forming said plurality of keep-alive messages 
together (Rosenberg, page 2, paragraph beginning "On the other hand..."). 

• <Claim 68> 

The method of claim 67, wherein each of said plurality of keep-alive messages 
contains an identifier of a corresponding PPP session, wherein said generating 
comprises: selecting said identifier of each of said plurality of keep-alive messages 
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(Rosenberg, pages 3-5, section 2); and forming said aggregated request packet from 
said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated request 
packet contains less data than said plurality of keep-alive messages together 
(Rosenberg, page 2, paragraph beginning "On the other hand...")* 

• <Claim 70> 

The aggregation device of claim 30, wherein said reply generator includes less 
data in said aggregated request packet than the data forming said plurality of keep- 
alive messages together (Rosenberg, page 2, paragraph beginning "On the other 
hand..."). 

• <Claim 7i> 

The aggregation device of claim 70, wherein each of said plurality of keep-alive 
messages contains an identifier of a corresponding PPP session, wherein said reply 
generator operates to: select said identifier of each of said plurality of keep-alive 
messages (Rosenberg, pages 3-5, section 2); and form said aggregated request packet 
from said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated 
request packet contains less data than said plurality of keep-alive messages together 
(Rosenberg, page 2, paragraph beginning "On the other hand..."). 

• <Claim 73> 

The computer readable medium of claim 37, wherein said generating includes 
less data in said aggregated request packet than the data forming said plurality of 
keep-alive messages together (Rosenberg, page 2, paragraph beginning "On the other 
hand..."). 
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• <Claim 74> 

The computer readable medium of claim 73, wherein each of said plurality of 
keep-alive messages contains an identifier of a corresponding PPP session, wherein 
said generating comprises: selecting said identifier of each of said plurality of keep- 
alive messages (Rosenberg, pages 3-5, section 2); and forming said aggregated request 
packet from said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated 
request packet contains less data than said plurality of keep-alive messages together 
(Rosenberg, page 2, paragraph beginning "On the other hand..."). 

• <Claim 76> 

The aggregation device of claim 21, wherein said means for generating includes 
less data in said aggregated request packet than the data forming said plurality of 
keep-alive messages together (Rosenberg, page 2, paragraph beginning "On the other 
hand..."). 

• <Claim 77> 

The aggregation device of claim 76, wherein each of said plurality of keep-alive 
messages contains an identifier of a corresponding PPP session, wherein said means 
for generating operates to: select said identifier of each of said plurality of keep-alive 
messages (Rosenberg, pages 3-5, section 2); and form said aggregated request packet 
from said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated 
request packet contains less data than said plurality of keep-alive messages together 
(Rosenberg, page 2, paragraph beginning "On the other hand..."). 
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Since the combination of Ketcham, Pereira, and Rosenberg discloses all of the above 
limitations, claims 67, 68, 70, 71, 73, 74, 76, and 77 are rejected. 

(10) Response to Argument 

I. The rejection of Appellant's claims under siq^(a) should be affirmed 

BECAUSE THE CITED REFERENCES IN COMBINATION TEACH ALL OF THE CLAIMED 
LIMITATIONS. 

There must be some articulated reason with some rational underpinning to support 
the legal conclusion of obviousness. KSR Int'l v. Teleflex, Inc. , 127 S. Ct. 1727, 1741 (2007). 
Such reasoning can be based on interrelated teachings of multiple patents and the background 
knowledge possessed by a person having ordinary skill in the art. KSR , 127 S. Ct. at 1740-41. 

The motivation to combine references under §103 must come from a teaching or 
suggestion within the prior art, within the nature of the problem to be solved, or within the 
general knowledge of a person of ordinary skill in the art, to look to particular sources, select 
particular elements, and to combine them as combined by the inventor. Ruiz v. A.B. Chance 
Co. , 234 F.3d 654, 665 (Fed. Cir. 2000). An implicit motivation to combine exists when the 
combination of references results in a product or process that is more desirable. DyStar 
Textilfarben GmbH & Co. Deutschland KG v. C.H. Patrick Co. , 464 F.3d 1356, 1368 (Fed. 
Cir. 2006). 

A. Claims 1, is, 21, and 37 

Appellant sets forth three reasons why the rejection of claims 1, 15, 21, and 37 is 
improper: (1) the action has not set forth how embodiments constructed from the combined 
teachings of Ketcham and Pereira would operate akin to the features of claim 1; (2) the action 
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has not set forth why one skilled in the art would have combined Ketcham and Pereira; and 
(3) one of skill in the art would not have combined Ketcham and Pereira to arrive at the 
claimed invention. None of these reasons should be found persuasive. 

As to Appellant's first reason, it is unclear to what legal test Appellant is referring. 
There is no requirement under §i03(a) that combined references must "operate akin to the 
features" of the claimed invention. Beyond this conclusory statement, Appellant fails to 
provide any another reasoning to support their first argument. 

As to Appellant's second reason, Appellant merely asserts that "[a]s the burden of Pi 
is not believed to be met, the burden of P2 is also not believed to have been met." 
(Appellant's brief 14:22-23). Again, it is unclear to what legal test Appellant is referring. 

In response to Appellant's first two reasons, Examiner maintains that there was a 
clear suggestion in Pereira to modify Ketcham and that the combined teachings of Ketcham 
and Pereira yield the same features as claimed in claim 1. The rejection clearly set forth that 
Ketcham taught every claim feature except for the use of a keep-alive message or poll request. 
Pereira was relied upon to teach a keep-alive message (in the form of a poll request that 
maintains the connection) (Col. 4, 11. 31-40). One of ordinary skill in the art would have been 
motivated to modify Ketcham with Pereira's teaching because the combination improves 
upon Ketcham by providing improved connection oriented protocol for systems that 
maintain a number of end users that share a common link. (Pereira col. 4, 11. 12-17). 

As to Appellant's third reason, Appellant argues that one of ordinary skill in the art 
would not have been motivated to combine Ketcham and Pereira to arrive at the claimed 
invention. Specifically, Appellant cites Pereira's disclosure that would allow polling traffic 
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from one communication session while blocking the polling traffic of other sessions in order 
to maintain the common link shared between sessions (Pereira, col. 4, 11. 31-40). Appellant 
argues that the claimed limitation that "an aggregated request packet... includes data 
indicating that the status of said PPP sessions is requested" is in direct contrast to Pereira's 
teachings. (Br. 15:15-18). 

Appellant's argument should be found unpersuasive because while Pereira may teach 
blocking certain polling traffic from other sessions, Pereira does not teach blocking status 
data within the allowed polling traffic. There are no features in Appellant's claim that 
require all keep-alive messages to be transmitted from all sessions which would be in direct 
contrast to Pereira. 

Instead, Appellant's claim simply requires requesting the status of a single session and 
generating a single aggregate request packet that contains data indicating the status of the 
session. Ketcham describes a system in which different types of data packets can be 
aggregated together (col. 7, 1. 62 - col. 8, 1. 4); Pereira discloses generating keep-alive 
messages which include data that request the status of sessions (col. 6, 11. 1-6). In response to 
a keep alive message, Pereira's system waits for a response from the session indicating that 
the session is still alive. Therefore, the combination of Ketcham and Pereira teach the 
features as claimed. 

B. Claims 2, 1, 22, 38, and 47 

Appellant argues that "the probability of success of the combination of Ketcham and 
Pereira operating as in claim 2 is random." (Br. 17). Appellant's argument is essentially that 
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there was no reasonable expectation of success in combining Ketcham and Pereira because 
Ketcham would not include the status of the sessions in an aggregated reply packet. (Br. 17). 

Appellant's argument is based on Ketcham's teaching that in aggregating packets, a 
router waits a predetermined time period after receiving a first packet. If the router receives a 
subsequent packet that will follow the same route or have the same destination as the first 
packet within the time period, the router will aggregate the packets. Appellant argues then 
that the chances that the status of the session being included in the aggregated packet is 
"random" because the inclusion of the status into an aggregate packet is based on receiving 
the status information within the time period. 

However, Appellant's argument confuses the standards for a reasonable expectation 
of success. Even assuming the accuracy of Appellant's argument that the chances of 
including status information within an aggregated packet is "random," the test is not 
centered on whether success would be random but whether success could be reasonably 
predicted. See MPEP §2143.02 . Here, one of ordinary skill in the art would have reasonably 
expected success in combining Ketcham and Pereira. Pereira teaches that upon sending a first 
keep-alive message, a computer waits a certain time period in response. If a reply is received 
within the time period, the connection is maintained because the session is still alive, (col. 6, 
11. 1-6). 

Pereira teaches waiting for the first reply to the keep-alive message in order to 
maintain the connection. Thus, one would have reasonably expected that combining 
Ketcham's teaching of waiting a certain time period for aggregating packets and Pereira's 
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teaching of waiting a certain time period to receive a first reply to a keep-alive message 
would be successful. 

C. Claims 4, 23, and 40 

Appellant argues that the combination of Ketcham and Pereira does not disclose 
sending keep-alive reply message without waiting for said aggregated reply packet. However, 
the combination of Ketcham and Pereira do disclose this feature. 

Ketcham discloses sending response packets to terminals that do not support 
aggregated packets. (Col. 3, 11. 14-20 and col. 4, 11. 58-63). Combined with Pereira, the 
combination teaches submitting keep alive reply messages to those terminals that do not 
support aggregated packets. The keep alive reply message is sent without the need of waiting 
for the aggregated reply packet because the terminal does not support aggregated packets. 

D. Claims s, 17. 24. and 41 

Appellant argues that the combination of Ketcham, Pereira and Chao do not disclose a 
remote status table indicating the status of sessions supported by the aggregation device. 
Appellant specifically argues that Chao's topology map is different from the claimed remote 
status table because "the claimed aggregation device may be supporting several point-to-point 
to [sic] sessions to the same peer aggregation device, potentially on different paths." (Br. 20). 
Appellant is arguing limitations not present in the claims. 

Claim 5 merely requires a remote status table that indicates the status of sessions 
supported by an aggregation device and updating the table with information in an aggregated 
reply packet. The combination of Ketcham, Pereira and Chao teach these features. 
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Chao's topology map reads on Appellant's claimed remote status table because Chao's 
topology map indicates the status of sessions within the network. (Col 2, 11. 32-37 and col. 5, 
11. 46-50). Chao discloses maintaining the status of connections within the network, where 
Chao's connections read on Appellant's claimed sessions. Chao also teaches updating the 
topology map based on reply packets received from polled nodes. (Col. 6, 11. 33-48). 

The combination of Ketcham and Pereira's teachings of aggregating keep-alive 
messages and Chao's topology status map teach the features as claimed. One would have 
been motivated to modify Ketcham and Pereira with Chao's teachings because the 
combination improves Ketcham and Pereira by providing a method for monitoring a point- 
to-point network. (Chao, col. 2, 11. 15-24). 

E. Claims 67, 68, 70, 71. 73, 74, 76, and 77 

Appellant argues that the rejection relies upon impermissible hindsight to combine 
Ketcham, Pereira and Rosenberg. (Br. 22). Then, Appellant specifically argues that Rosenberg 
is directed to a different technological area from the other references relied upon in the 
rejection. (Br. 22). Appellant concludes that "the intuitive connection required between the 
references is simply lacking." (Br. 22). 

Appellant does not argue that the combined references do not teach the claimed 
features. Appellant merely asserts that the references cannot be combined. There is no 
express requirement that prior art references must be in the same field of invention in order 
to be combined. Regardless, like Pereira, Rosenberg is directed to aggregating data from 
multiple users into a single packet (pg. 1, abstract). Rosenberg taught the limitations as 
claimed and improves upon the combination of Ketcham and Pereira by improving the 
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efficiency of sending packets through a network by reducing the amount of traffic. 
(Rosenberg, pg. 2, "On the other hand..." and Pereira, coL 4, lines 12-17). 

F. Claims 79-85 

Appellant argues that the combination of Ketcham and Pereira does not disclose that 
the receiving, generating, and sending functionalities are performed in a single device. (Br. 
22-23). Appellant then argues that Pereira's central node combined with Ketcham's router 
would not result in the claimed invention because "the aggregated request packet would not 
indicate that the status of multiple PPP sessions is requested." (Br. 23). 

The rejection of claims 79-85 did not rely upon Pereira's central node to teach the 
receiving, generating, and sending functions within a single device. As set forth in the 
rejection, Ketcham taught all of these functions. 

It should also be noted that Appellant is again arguing limitations not in the claims. 
There is no language in the claims directed towards requesting the status of multiple PPP 
sessions. The claims merely require requesting the status of a single session. 

G. Claims io, 2S, 3Q, and 42 

Appellant argues that the combination of Ketcham and Pereira do not disclose the 
claimed step of examining an aggregated request packet to determine that the status of a 
plurality of point-to-point sessions is requested. (Br. 23). Appellant specifically argues that 
Ketcham does not disclose that the content of a received aggregated request packet is 
examined to determine that the status of the sessions is requested. 

Appellant's arguments ignore the combination of Ketcham and Pereira which when 
combined yield the claimed features. The rejection relied on Pereira to disclose poll requests 
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which are used to request the status of point-to-point sessions that are on different 
communication links. Ketcham's teaches that the aggregate packets are examined. Therefore, 
the combination of Ketcham and Pereira yields the function of examining aggregate packets, 
where the aggregate packets contain the status requests for each of the point-to-point 
sessions. 

H. Claims 11, 26, 31, and 43 

Appellant argues that the combination of Ketcham, Pereira, and Chao do not disclose 
the feature of accessing a local status table which contains the status information of at least 
some of said plurality of point-to-point sessions. (Br. 25). Appellant specifically argues that 
the combination of Ketcham and Pereira would be inconsistent with the claimed feature. (Br. 

25). 

Appellant's argument ignore that the rejection relied upon Chao to teach accessing a 
local status table which contains the status information of at least some of said plurality of 
point-to-point sessions Chao teaches retrieving local connectivity information for the 
connections from a node; the connectivity information reads on the status information of the 
session. (Col. 5, 11. 52-58). As discussed with respect to claims 5, 17, 24, and 41, Chao improves 
upon the combination of Ketcham and Pereira by providing a method for monitoring point- 
to-point connections. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 
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For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 

DC 

November 14, 2007 
Conferees: 
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